Please address the comments from this code review:

## Overall Comments
- When building `propagated_composite_cv_ids` in `ContentView::IncrementalUpdates#plan`, consider calling `.uniq` (and possibly `.compact`) on the mapped IDs to avoid passing duplicates or nils through to the auto-publish exclusion logic.
- The new tests rely on stubbing `ContentViewVersion.find(nil)` and other internals of the action; using a concrete `old_version` ID instead of `nil` would make the tests less coupled to the implementation and more resilient to future refactors.

## Individual Comments

### Comment 1
<location> `test/actions/katello/content_view_version/incremental_update_test.rb:20` </location>
<code_context>
+      let(:component_cv) { katello_content_views(:library_dev_view) }
+      let(:component_version) { component_cv.versions.first }
+      let(:composite_cv) { katello_content_views(:composite_view) }
+      let(:mock_output) { {} }
+
+      before do
</code_context>

<issue_to_address>
**suggestion (testing):** Consider asserting `auto_publish_content_view_version_id` in addition to `auto_publish_content_view_ids`

Right now the tests only verify the filtering of `auto_publish_content_view_ids`, but not the behavior of `auto_publish_content_view_version_id`, which is also updated in the implementation.

In addition to the existing assertions, please:
- In a positive case (e.g., `includes composites in auto-publish list when not propagated`), assert `mock_output[:auto_publish_content_view_version_id] == component_version.id`.
- In negative cases (composite CV, non-latest version), assert that `mock_output[:auto_publish_content_view_version_id]` is `nil` or absent, matching the expectations for `auto_publish_content_view_ids`.

This will ensure the tests fully cover the auto-publish output contract.

Suggested implementation:

```ruby
    it 'includes composites in auto-publish list when not propagated' do
      # existing setup / execution
      perform_action action, input

      assert_equal [composite_cv.id], mock_output[:auto_publish_content_view_ids]
      assert_equal component_version.id, mock_output[:auto_publish_content_view_version_id]
    end

```

```ruby
    it 'does not include composite cv in auto-publish list when composite cv is the target' do
      # existing setup / execution
      perform_action action, input

      assert_empty mock_output[:auto_publish_content_view_ids]
      assert_nil mock_output[:auto_publish_content_view_version_id]
    end

```

```ruby
    it 'does not include composite in auto-publish list when component version is not latest' do
      # existing setup / execution
      perform_action action, input

      assert_empty mock_output[:auto_publish_content_view_ids]
      assert_nil mock_output[:auto_publish_content_view_version_id]
    end

```

I assumed the test names and assertion shapes based on your description. To wire this into your actual file:

1. Locate the example that currently asserts `mock_output[:auto_publish_content_view_ids]` and whose description matches “includes composites in auto-publish list when not propagated”; add `assert_equal component_version.id, mock_output[:auto_publish_content_view_version_id]` right after the existing assertion.
2. For each “negative” example where you assert an empty/absent `auto_publish_content_view_ids` (e.g. composite CV as target, non-latest version cases), add `assert_nil mock_output[:auto_publish_content_view_version_id]` (or the equivalent expectation style you are using) next to the existing `mock_output[:auto_publish_content_view_ids]` assertion.
3. If your test suite uses `test "..." do` instead of `it '...' do`, or uses `refute`/`wont_be_nil` instead of `assert_nil`, adapt the snippets accordingly while keeping the semantics: positive case → equals `component_version.id`, negative cases → `nil`.
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `IncrementalUpdateTest`, the stub `ContentViewVersion.stubs(:find).with(nil)` coupled with not setting `old_version` in the input makes the test rely on an implicit `nil` argument; consider explicitly setting `old_version` (or avoiding the `find(nil)` path) so the tests are less brittle against future changes in the action inputs.
- The test case `handles partial propagation with multiple composites` fakes a second composite ID via `composite_cv.id + 100`; it would be more robust to create a real second composite content view (with a corresponding version) so the test reflects realistic data and avoids relying on ID arithmetic.

## Individual Comments

### Comment 1
<location> `test/actions/katello/content_view_version/incremental_update_test.rb:9-10` </location>
<code_context>
+    include Support::Actions::Fixtures
+    include FactoryBot::Syntax::Methods
+
+    before :all do
+      User.current = users(:admin)
+    end
+
</code_context>

<issue_to_address>
**suggestion (testing):** Prefer per-test setup to avoid leaking User.current across test cases

Using `before :all` here shares `User.current` across examples and can leak state as tests are added or cleanup changes. Please use per-example setup (e.g., `before` or `setup`) so each test runs with its own explicitly set `User.current` and doesn’t depend on cross-test state.
</issue_to_address>

### Comment 2
<location> `test/actions/katello/content_view_version/incremental_update_test.rb:41-43` </location>
<code_context>
+        # Stub repositories to avoid the content comparison logic in run
+        component_version.stubs(:repositories).returns([])
+
+        # Stub find for old_version (will be nil in most tests, stub to return a version with empty repos)
+        old_version_stub = stub('old_version', repositories: [])
+        ::Katello::ContentViewVersion.stubs(:find).with(nil).returns(old_version_stub)
+      end
+
</code_context>

<issue_to_address>
**nitpick:** Remove or narrow the stub for ContentViewVersion.find(nil) if it’s no longer needed

This stub is described as for `old_version`, but `run` only calls `ContentViewVersion.find` with `input[:new_content_view_version_id]`, and each example stubs that explicitly. The `find(nil)` stub may never be used. If it isn’t, please remove it; if it is, add a brief comment or assertion indicating which code path requires `find(nil)` so it’s clear to future readers.
</issue_to_address>